Embora o último ano ou dois tenham visto um número de propostas de extensões propondo a aliança ao Bitcoin, sempre houve uma suspeita entre os especialistas de que as alianças podem ser possíveis sem quaisquer extensões. A evidência para isso veio em duas formas: um repertório em expansão de cálculos anteriormente considerados impossíveis (culminando no projeto BitVM para implementar cada opcode RISC-V) e uma série de "quase-acertos" pelos quais os desenvolvedores do Bitcoin encontraram maneiras de que as alianças teriam sido possíveis, se não fosse por alguma peculiaridade histórica obscura da .
Ethan Heilman, Avihu Levy, Victor Kobolov e eu desenvolvemos um esquema que prova que essa suspeita estava bem fundamentada. Nosso esquema,Collider*, permite pactos no Bitcoin hoje, sob suposições criptográficas razoavelmente razoáveis e a um custo provável em torno de 50 milhões de dólares por transação (além de algum hardware P&D).*
Apesar dos custos extravagantes para usar o Collider, configurá-lo é muito barato e fazê-lo (juntamente com um mecanismo de gastos comuns, usando Taproot para separar os dois) pode muito bem salvar suas moedas caso um computador quântico apareça do nada e exploda o .
Sem dúvida, muitos leitores, depois de lerem essas afirmações, estão levantando uma sobrancelha para o céu. Quando você terminar de ler este artigo, a outra estará tão alta quanto.
Convénios
O contexto desta discussão, para aqueles que não estão familiarizados, é que o Bitcoin tem uma linguagem de programação incorporada, chamada Bitcoin, que é usada para autorizar a despesa de moedas. Nos seus primeiros dias, continha um conjunto rico de opcodes aritméticos que poderiam ser usados para implementar cálculos arbitrários. Mas no verão de 2010, Satoshi desativou muitos destes a fim de suprimir uma série de bugs sérios. (Voltar à versão pré-2010 de é o objetivo do Grande Projeto de Restauração; OP_CAT é uma proposta menos ambiciosa na mesma direção.) A ideia de covenants -- transações que usam para controlar a quantidade e o destino das suas moedas -- não apareceu até vários anos depois, e a compreensão de que estes opcodes teriam sido suficientes para implementar covenants só surgiu mais tarde. Nesse ponto, a comunidade já era demasiado grande e cautelosa para simplesmente "reabilitar" os velhos opcodes da mesma forma que tinham sido desativados.
Os pactos são construções hipotéticas que permitiriam aos utilizadores controlar não apenas as condições em que as moedas são gastas, mas também o seu destino. Esta é a base para muitas construções em Bitcoin, desde cofres e carteiras com limitação de taxas, até novos mecanismos de mercado de taxas como pools de pagamento, até construções menos dignas como finanças distribuídas e MEV. Milhões de palavras foram gastas debatendo a desejabilidade dos pactos e o que fariam à natureza do Bitcoin.
Neste artigo, evitarei este debate e argumentarei simplesmente que os convênios já são possíveis no Bitcoin; que eventualmente descobriremos como eles são possíveis (sem grande custo computacional ou suposições criptográficas questionáveis); e que nosso debate sobre novas extensões do Bitcoin não deve ser enquadrado como se as mudanças individuais fossem a linha divisória entre um futuro sem convênios ou com convênios para o Bitcoin.
História
Ao longo dos anos, desenvolveu-se uma tradição de encontrar maneiras criativas de fazer coisas não triviais mesmo com recursos limitados. A Lightning Network foi um exemplo disso, assim como ideias menos conhecidas, como pagamentos probabilísticos ou recompensas por colisões em funções de hash. Casos específicos obscuros, como o bug SIGHASH_SINGLE ou o uso de recuperação de chave pública para obter um "hash de transação" dentro do interpretador, foram observados e explorados, mas ninguém nunca encontrou uma maneira de torná-los úteis. Enquanto isso, o próprio Bitcoin evoluiu para ser mais bem definido, fechando muitas dessas portas. Por exemplo, o Segwit eliminou o bug SIGHASH_SINGLE e separou explicitamente os dados do programa dos dados da testemunha; o Taproot eliminou a recuperação de chave pública, que proporcionava flexibilidade, mas poderia comprometer a segurança de assinaturas adaptativas ou multiassinaturas.
Apesar dessas mudanças, a pirataria continuou, assim como a crença entre os mais fanáticos de que de alguma forma, algum caso limite poderia ser encontrado que permitisse o suporte de aliança em Bitcoin. No início dos anos 2020, dois desenvolvimentos em particular causaram impacto. Um deles foi a minha própria descoberta de que alianças baseadas em assinaturas não tinham morrido com a recuperação da chave pública e que, em particular, se tivéssemos até mesmo um único opcode desativado de volta -- OP_CAT -- isso seria suficiente para uma construção de aliança bastante eficiente. O outro foi o BitVM, uma maneira inovadora de realizar grandes computações em 01928374656574839201 transações, o que inspirou uma tremenda quantidade de pesquisa em cálculos básicos dentro de transações individuais.
Estes dois desenvolvimentos inspiraram muita atividade e entusiasmo em torno dos pactos, mas também cristalizaram o nosso pensamento sobre as limitações fundamentais do . Em particular, parecia que os pactos poderiam ser impossíveis sem novos códigos de operação, uma vez que os dados da transação eram apenas alimentados através de assinaturas de 64 bytes e chaves públicas de 32 bytes, enquanto os códigos de operação que suportavam o BitVM só podiam trabalhar com objetos de 4 bytes. Esta divisão foi denominada "Pequeno " e "Grande ", e encontrar uma ponte entre os dois tornou-se sinônimo (pelo menos na minha mente) de encontrar uma construção de pacto.
Encriptação Funcional e PIPEs
Também foi observado que, com um pouco de matemática lunar, pode ser possível fazer pactos inteiramente dentro das assinaturas em si, sem nunca sair do Big . Esta ideia foi articulada por Jeremy Rubin em seu artigo FE'd Up Covenants, que descreveu como implementar pactos usando uma primitiva cripto hipotética chamada encriptação funcional. Meses depois, Misha Komorov propôs um esquema específico chamado PIPEs que parece tornar esta ideia hipotética uma realidade.
Este é um desenvolvimento emocionante, embora sofra de duas limitações principais: uma é que envolve uma configuração confiável, o que significa que a pessoa que cria o pacto é capaz de contornar suas regras. (Isto é bom para algo como cofres, em que o proprietário das moedas pode ser confiável para não minar sua própria segurança; mas não é bom para algo como piscinas de pagamento onde as moedas no pacto não são de propriedade do criador do pacto.) A outra limitação é que envolve criptografia de ponta com propriedades de segurança pouco claras. Esta última limitação desaparecerá com mais pesquisa, mas a configuração confiável é inerente à abordagem funcional-01928374656574839201.
Collider
Esta visão geral leva-nos à situação atual: gostaríamos de encontrar uma maneira de implementar pactos usando a forma existente de Bitcoin e acreditamos que a maneira de fazer isso é encontrar algum tipo de ponte entre o "Big" de assinaturas de transação e o "Pequeno" de cálculos arbitrários. Parece que nenhum código de operação pode formar diretamente esta ponte (ver Apêndice A em nosso artigo para uma classificação de todos os códigos de operação em termos de seu tamanho de entrada e saída). Uma ponte, se existisse, seria algum tipo de construção que pegasse um objeto grande único e demonstrasse que era exatamente igual à concatenação de vários objetos pequenos. Parece, com base em nossa classificação de códigos de operação, que isso é impossível.
No entanto, em criptografia, frequentemente enfraquecemos noções como "exatamente iguais", em vez disso, usando noções como "computacionalmente indistinguíveis" ou "estatisticamente indistinguíveis", e assim evitamos resultados impossíveis. Talvez, ao usar as construções criptográficas incorporadas do Big -- hashes e assinaturas de curva elíptica -- e ao espelhá-las usando construções BitVM no Small , poderíamos encontrar uma forma de mostrar que um grande objeto era "computacionalmente indistinguível" de uma série de objetos pequenos? Com o Collider, foi exatamente isso que fizemos.
O que isso significa? Bem, lembre-se da recompensa por colisão de função hash que mencionamos anteriormente. A premissa dessa recompensa é que qualquer pessoa que consiga "colidir" uma função hash, fornecendo duas entradas que tenham a mesma saída de hash, pode provar em Big que o fez e, assim, reivindicar a recompensa. Como o espaço de entrada de uma função hash é muito maior (todos os bytes de até 520 bytes de tamanho) do que o espaço de saída (bytes de exatamente 32 bytes de tamanho), matematicamente falando, deve haver muitas colisões desse tipo. E ainda assim, com exceção do SHA1, ninguém encontrou uma maneira mais rápida de encontrar essas colisões do que chamando a função hash repetidamente e verificando se o resultado corresponde ao de uma tentativa anterior.
Isso significa que, em média, para uma função de hash de 160 bits como SHA1 ou RIPEMD160, um usuário precisará fazer pelo menos 2^80 trabalhos, ou um milhão de milhão de milhão de milhão de iterações, para encontrar uma colisão. (No caso do SHA1, há um atalho se o usuário puder usar entradas de uma forma específica; mas nossa construção proíbe essas entradas, então, para nossos propósitos, podemos ignorar esse ataque.) Isso pressupõe que o usuário tenha uma quantidade efetivamente infinita de memória para trabalhar; com suposições mais realistas, precisamos adicionar outro fator de cerca de cem ou algo assim.
Se imaginarmos que o SHA1 e o RIPEMD160 podem ser calculados tão eficientemente quanto os ASICs de Bitcoin calculam o SHA256, então o custo de tal cálculo seria aproximadamente o mesmo que 200 blocos, ou cerca de 625 BTC (46 milhões de dólares). Este é muito dinheiro, mas muitas pessoas têm acesso a essa quantia, então isso é possível.
Para encontrar uma colisão triplo, ou três inputs que resultam na mesma coisa, seria necessário cerca de 2^110 de trabalho, mesmo com suposições muito generosas sobre o acesso à memória. Para obter este número, precisamos adicionar mais um fator de 16 milhões ao nosso custo -- elevando o total para mais de 700 biliões de dólares. Isto também é muito dinheiro, e um ao qual ninguém tem acesso hoje.
A essência da nossa construção é a seguinte: para provar que uma série de pequenos objetos é equivalente a um único objeto grande, primeiro encontramos uma colisão de hash entre nosso objeto alvo (que assumimos poder ser realeatorizado de alguma forma, caso contrário estaríamos fazendo uma "busca de segunda imagem" em vez de uma busca de colisão, que seria muito mais difícil) e um "objeto testador de equivalência". Esses objetos testadores de equivalência são construídos de forma que possam ser facilmente manipulados tanto em Big quanto em Small.
A nossa construção verifica, em Bitcoin, que o nosso grande objeto colide com o nosso testador de equivalência (usando exatamente os mesmos métodos que na recompensa de colisão de hash) e que a nossa série de pequenos objetos colide com o testador de equivalência (usando construções complexas parcialmente copiadas do projeto BitVM e descritas detalhadamente no artigo). Se estes testes passarem, então ou os nossos objetos pequenos e grandes eram iguais, ou o utilizador encontrou uma tripla colisão: dois objetos diferentes que colidem ambos com o testador. Pelo nosso argumento acima, isto é impossível.
Conclusão
Unir o Pequeno e o Grande é a parte mais difícil da construção da nossa aliança. Para passar desta ponte para uma aliança real, há mais alguns passos, que são comparativamente fáceis. Em particular, uma aliança pede primeiro ao utilizador para assinar a transação usando a chave especial "chave de gerador", que podemos verificar usando o opcode OP_CHECKSIG. Usando a ponte, quebramos esta assinatura em pedaços de 4 bytes. Em seguida, verificamos que o seu nonce também era igual à chave do gerador, o que é fácil de fazer uma vez que a assinatura foi quebrada. Finalmente, usamos técnicas do truque de Schnorr para extrair dados da transação da assinatura, que então podem ser restritos da forma que a aliança desejar.
Existem algumas outras coisas que podemos fazer: o Apêndice C descreve uma construção de assinatura de anel que permitiria que moedas fossem assinadas por uma das várias chaves públicas, sem revelar qual foi usada. Nesse caso, usamos a ponte para dividir a chave pública, em vez da assinatura. Fazê-lo nos dá uma melhoria significativa na eficiência em relação à construção do pacto, por razões técnicas relacionadas ao Taproot e detalhadas no artigo.
Uma aplicação final à qual eu quero chamar a atenção, discutida brevemente na seção 7.2 do artigo, é que podemos usar nossa construção de contrato para extrair o hash da transação de uma assinatura Schnorr e, em seguida, simplesmente re-assinar o hash usando uma assinatura Lamport.
Por que faríamos isso? Como argumentado no link acima, assinar a assinatura de Lamport desta forma a torna uma assinatura segura quanticamente nos dados da transação; se essa construção fosse a única maneira de assinar algumas moedas, elas estariam imunes a roubo por um computador quântico.
Claro, uma vez que nossa construção requer dezenas de milhões de dólares para ser usada, ninguém faria desta construção a única forma de assinar para suas moedas. Mas nada impede alguém de adicionar esta construção às suas moedas, além de seus métodos existentes de gasto não seguros para computação quântica.
Então, se acordássemos amanhã e descobríssemos que existiam computadores quânticos baratos capazes de quebrar as assinaturas do Bitcoin, poderíamos propor uma forquilha suave de emergência que desativasse todas as assinaturas de curva elíptica, incluindo tanto os gastos de chaves Taproot quanto o opcode OP_CHECKSIG. Isso efetivamente congelaria as moedas de todos, mas se a alternativa fosse que as moedas de todos fossem livremente roubáveis, talvez não fizesse diferença alguma. Se essa forquilha suave de desativação de assinatura permitisse o opcode OP_CHECKSIG quando chamado com a chave do gerador (tais assinaturas não fornecem segurança de qualquer maneira e são úteis apenas como um bloco de construção para construções complexas como a nossa), então os usuários da nossa construção de assinatura de Lamport poderiam continuar gastando suas moedas livremente, sem medo de apreensão ou roubo.
Claro, eles precisariam gastar dezenas de milhões de dólares para fazer isso, mas isso é muito melhor do que "impossível"! E esperamos que esse custo caia drasticamente, à medida que as pessoas se baseiam em nossa pesquisa.
Este é um post de convidado de Andrew Poelstra. As opiniões expressas são inteiramente deles e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Collider_: Um Pacto de Bitcoin de $50M Sem Novos Opcodes
Embora o último ano ou dois tenham visto um número de propostas de extensões propondo a aliança ao Bitcoin, sempre houve uma suspeita entre os especialistas de que as alianças podem ser possíveis sem quaisquer extensões. A evidência para isso veio em duas formas: um repertório em expansão de cálculos anteriormente considerados impossíveis (culminando no projeto BitVM para implementar cada opcode RISC-V) e uma série de "quase-acertos" pelos quais os desenvolvedores do Bitcoin encontraram maneiras de que as alianças teriam sido possíveis, se não fosse por alguma peculiaridade histórica obscura da .
Ethan Heilman, Avihu Levy, Victor Kobolov e eu desenvolvemos um esquema que prova que essa suspeita estava bem fundamentada. Nosso esquema, Collider*, permite pactos no Bitcoin hoje, sob suposições criptográficas razoavelmente razoáveis e a um custo provável em torno de 50 milhões de dólares por transação (além de algum hardware P&D).*
Apesar dos custos extravagantes para usar o Collider, configurá-lo é muito barato e fazê-lo (juntamente com um mecanismo de gastos comuns, usando Taproot para separar os dois) pode muito bem salvar suas moedas caso um computador quântico apareça do nada e exploda o .
Sem dúvida, muitos leitores, depois de lerem essas afirmações, estão levantando uma sobrancelha para o céu. Quando você terminar de ler este artigo, a outra estará tão alta quanto.
Convénios
O contexto desta discussão, para aqueles que não estão familiarizados, é que o Bitcoin tem uma linguagem de programação incorporada, chamada Bitcoin, que é usada para autorizar a despesa de moedas. Nos seus primeiros dias, continha um conjunto rico de opcodes aritméticos que poderiam ser usados para implementar cálculos arbitrários. Mas no verão de 2010, Satoshi desativou muitos destes a fim de suprimir uma série de bugs sérios. (Voltar à versão pré-2010 de é o objetivo do Grande Projeto de Restauração; OP_CAT é uma proposta menos ambiciosa na mesma direção.) A ideia de covenants -- transações que usam para controlar a quantidade e o destino das suas moedas -- não apareceu até vários anos depois, e a compreensão de que estes opcodes teriam sido suficientes para implementar covenants só surgiu mais tarde. Nesse ponto, a comunidade já era demasiado grande e cautelosa para simplesmente "reabilitar" os velhos opcodes da mesma forma que tinham sido desativados.
Os pactos são construções hipotéticas que permitiriam aos utilizadores controlar não apenas as condições em que as moedas são gastas, mas também o seu destino. Esta é a base para muitas construções em Bitcoin, desde cofres e carteiras com limitação de taxas, até novos mecanismos de mercado de taxas como pools de pagamento, até construções menos dignas como finanças distribuídas e MEV. Milhões de palavras foram gastas debatendo a desejabilidade dos pactos e o que fariam à natureza do Bitcoin.
Neste artigo, evitarei este debate e argumentarei simplesmente que os convênios já são possíveis no Bitcoin; que eventualmente descobriremos como eles são possíveis (sem grande custo computacional ou suposições criptográficas questionáveis); e que nosso debate sobre novas extensões do Bitcoin não deve ser enquadrado como se as mudanças individuais fossem a linha divisória entre um futuro sem convênios ou com convênios para o Bitcoin.
História
Ao longo dos anos, desenvolveu-se uma tradição de encontrar maneiras criativas de fazer coisas não triviais mesmo com recursos limitados. A Lightning Network foi um exemplo disso, assim como ideias menos conhecidas, como pagamentos probabilísticos ou recompensas por colisões em funções de hash. Casos específicos obscuros, como o bug SIGHASH_SINGLE ou o uso de recuperação de chave pública para obter um "hash de transação" dentro do interpretador, foram observados e explorados, mas ninguém nunca encontrou uma maneira de torná-los úteis. Enquanto isso, o próprio Bitcoin evoluiu para ser mais bem definido, fechando muitas dessas portas. Por exemplo, o Segwit eliminou o bug SIGHASH_SINGLE e separou explicitamente os dados do programa dos dados da testemunha; o Taproot eliminou a recuperação de chave pública, que proporcionava flexibilidade, mas poderia comprometer a segurança de assinaturas adaptativas ou multiassinaturas.
Apesar dessas mudanças, a pirataria continuou, assim como a crença entre os mais fanáticos de que de alguma forma, algum caso limite poderia ser encontrado que permitisse o suporte de aliança em Bitcoin. No início dos anos 2020, dois desenvolvimentos em particular causaram impacto. Um deles foi a minha própria descoberta de que alianças baseadas em assinaturas não tinham morrido com a recuperação da chave pública e que, em particular, se tivéssemos até mesmo um único opcode desativado de volta -- OP_CAT -- isso seria suficiente para uma construção de aliança bastante eficiente. O outro foi o BitVM, uma maneira inovadora de realizar grandes computações em 01928374656574839201 transações, o que inspirou uma tremenda quantidade de pesquisa em cálculos básicos dentro de transações individuais.
Estes dois desenvolvimentos inspiraram muita atividade e entusiasmo em torno dos pactos, mas também cristalizaram o nosso pensamento sobre as limitações fundamentais do . Em particular, parecia que os pactos poderiam ser impossíveis sem novos códigos de operação, uma vez que os dados da transação eram apenas alimentados através de assinaturas de 64 bytes e chaves públicas de 32 bytes, enquanto os códigos de operação que suportavam o BitVM só podiam trabalhar com objetos de 4 bytes. Esta divisão foi denominada "Pequeno " e "Grande ", e encontrar uma ponte entre os dois tornou-se sinônimo (pelo menos na minha mente) de encontrar uma construção de pacto.
Encriptação Funcional e PIPEs
Também foi observado que, com um pouco de matemática lunar, pode ser possível fazer pactos inteiramente dentro das assinaturas em si, sem nunca sair do Big . Esta ideia foi articulada por Jeremy Rubin em seu artigo FE'd Up Covenants, que descreveu como implementar pactos usando uma primitiva cripto hipotética chamada encriptação funcional. Meses depois, Misha Komorov propôs um esquema específico chamado PIPEs que parece tornar esta ideia hipotética uma realidade.
Este é um desenvolvimento emocionante, embora sofra de duas limitações principais: uma é que envolve uma configuração confiável, o que significa que a pessoa que cria o pacto é capaz de contornar suas regras. (Isto é bom para algo como cofres, em que o proprietário das moedas pode ser confiável para não minar sua própria segurança; mas não é bom para algo como piscinas de pagamento onde as moedas no pacto não são de propriedade do criador do pacto.) A outra limitação é que envolve criptografia de ponta com propriedades de segurança pouco claras. Esta última limitação desaparecerá com mais pesquisa, mas a configuração confiável é inerente à abordagem funcional-01928374656574839201.
Collider
Esta visão geral leva-nos à situação atual: gostaríamos de encontrar uma maneira de implementar pactos usando a forma existente de Bitcoin e acreditamos que a maneira de fazer isso é encontrar algum tipo de ponte entre o "Big" de assinaturas de transação e o "Pequeno" de cálculos arbitrários. Parece que nenhum código de operação pode formar diretamente esta ponte (ver Apêndice A em nosso artigo para uma classificação de todos os códigos de operação em termos de seu tamanho de entrada e saída). Uma ponte, se existisse, seria algum tipo de construção que pegasse um objeto grande único e demonstrasse que era exatamente igual à concatenação de vários objetos pequenos. Parece, com base em nossa classificação de códigos de operação, que isso é impossível.
No entanto, em criptografia, frequentemente enfraquecemos noções como "exatamente iguais", em vez disso, usando noções como "computacionalmente indistinguíveis" ou "estatisticamente indistinguíveis", e assim evitamos resultados impossíveis. Talvez, ao usar as construções criptográficas incorporadas do Big -- hashes e assinaturas de curva elíptica -- e ao espelhá-las usando construções BitVM no Small , poderíamos encontrar uma forma de mostrar que um grande objeto era "computacionalmente indistinguível" de uma série de objetos pequenos? Com o Collider, foi exatamente isso que fizemos.
O que isso significa? Bem, lembre-se da recompensa por colisão de função hash que mencionamos anteriormente. A premissa dessa recompensa é que qualquer pessoa que consiga "colidir" uma função hash, fornecendo duas entradas que tenham a mesma saída de hash, pode provar em Big que o fez e, assim, reivindicar a recompensa. Como o espaço de entrada de uma função hash é muito maior (todos os bytes de até 520 bytes de tamanho) do que o espaço de saída (bytes de exatamente 32 bytes de tamanho), matematicamente falando, deve haver muitas colisões desse tipo. E ainda assim, com exceção do SHA1, ninguém encontrou uma maneira mais rápida de encontrar essas colisões do que chamando a função hash repetidamente e verificando se o resultado corresponde ao de uma tentativa anterior.
Isso significa que, em média, para uma função de hash de 160 bits como SHA1 ou RIPEMD160, um usuário precisará fazer pelo menos 2^80 trabalhos, ou um milhão de milhão de milhão de milhão de iterações, para encontrar uma colisão. (No caso do SHA1, há um atalho se o usuário puder usar entradas de uma forma específica; mas nossa construção proíbe essas entradas, então, para nossos propósitos, podemos ignorar esse ataque.) Isso pressupõe que o usuário tenha uma quantidade efetivamente infinita de memória para trabalhar; com suposições mais realistas, precisamos adicionar outro fator de cerca de cem ou algo assim.
Se imaginarmos que o SHA1 e o RIPEMD160 podem ser calculados tão eficientemente quanto os ASICs de Bitcoin calculam o SHA256, então o custo de tal cálculo seria aproximadamente o mesmo que 200 blocos, ou cerca de 625 BTC (46 milhões de dólares). Este é muito dinheiro, mas muitas pessoas têm acesso a essa quantia, então isso é possível.
Para encontrar uma colisão triplo, ou três inputs que resultam na mesma coisa, seria necessário cerca de 2^110 de trabalho, mesmo com suposições muito generosas sobre o acesso à memória. Para obter este número, precisamos adicionar mais um fator de 16 milhões ao nosso custo -- elevando o total para mais de 700 biliões de dólares. Isto também é muito dinheiro, e um ao qual ninguém tem acesso hoje.
A essência da nossa construção é a seguinte: para provar que uma série de pequenos objetos é equivalente a um único objeto grande, primeiro encontramos uma colisão de hash entre nosso objeto alvo (que assumimos poder ser realeatorizado de alguma forma, caso contrário estaríamos fazendo uma "busca de segunda imagem" em vez de uma busca de colisão, que seria muito mais difícil) e um "objeto testador de equivalência". Esses objetos testadores de equivalência são construídos de forma que possam ser facilmente manipulados tanto em Big quanto em Small.
A nossa construção verifica, em Bitcoin, que o nosso grande objeto colide com o nosso testador de equivalência (usando exatamente os mesmos métodos que na recompensa de colisão de hash) e que a nossa série de pequenos objetos colide com o testador de equivalência (usando construções complexas parcialmente copiadas do projeto BitVM e descritas detalhadamente no artigo). Se estes testes passarem, então ou os nossos objetos pequenos e grandes eram iguais, ou o utilizador encontrou uma tripla colisão: dois objetos diferentes que colidem ambos com o testador. Pelo nosso argumento acima, isto é impossível.
Conclusão
Unir o Pequeno e o Grande é a parte mais difícil da construção da nossa aliança. Para passar desta ponte para uma aliança real, há mais alguns passos, que são comparativamente fáceis. Em particular, uma aliança pede primeiro ao utilizador para assinar a transação usando a chave especial "chave de gerador", que podemos verificar usando o opcode OP_CHECKSIG. Usando a ponte, quebramos esta assinatura em pedaços de 4 bytes. Em seguida, verificamos que o seu nonce também era igual à chave do gerador, o que é fácil de fazer uma vez que a assinatura foi quebrada. Finalmente, usamos técnicas do truque de Schnorr para extrair dados da transação da assinatura, que então podem ser restritos da forma que a aliança desejar.
Existem algumas outras coisas que podemos fazer: o Apêndice C descreve uma construção de assinatura de anel que permitiria que moedas fossem assinadas por uma das várias chaves públicas, sem revelar qual foi usada. Nesse caso, usamos a ponte para dividir a chave pública, em vez da assinatura. Fazê-lo nos dá uma melhoria significativa na eficiência em relação à construção do pacto, por razões técnicas relacionadas ao Taproot e detalhadas no artigo.
Uma aplicação final à qual eu quero chamar a atenção, discutida brevemente na seção 7.2 do artigo, é que podemos usar nossa construção de contrato para extrair o hash da transação de uma assinatura Schnorr e, em seguida, simplesmente re-assinar o hash usando uma assinatura Lamport.
Por que faríamos isso? Como argumentado no link acima, assinar a assinatura de Lamport desta forma a torna uma assinatura segura quanticamente nos dados da transação; se essa construção fosse a única maneira de assinar algumas moedas, elas estariam imunes a roubo por um computador quântico.
Claro, uma vez que nossa construção requer dezenas de milhões de dólares para ser usada, ninguém faria desta construção a única forma de assinar para suas moedas. Mas nada impede alguém de adicionar esta construção às suas moedas, além de seus métodos existentes de gasto não seguros para computação quântica.
Então, se acordássemos amanhã e descobríssemos que existiam computadores quânticos baratos capazes de quebrar as assinaturas do Bitcoin, poderíamos propor uma forquilha suave de emergência que desativasse todas as assinaturas de curva elíptica, incluindo tanto os gastos de chaves Taproot quanto o opcode OP_CHECKSIG. Isso efetivamente congelaria as moedas de todos, mas se a alternativa fosse que as moedas de todos fossem livremente roubáveis, talvez não fizesse diferença alguma. Se essa forquilha suave de desativação de assinatura permitisse o opcode OP_CHECKSIG quando chamado com a chave do gerador (tais assinaturas não fornecem segurança de qualquer maneira e são úteis apenas como um bloco de construção para construções complexas como a nossa), então os usuários da nossa construção de assinatura de Lamport poderiam continuar gastando suas moedas livremente, sem medo de apreensão ou roubo.
Claro, eles precisariam gastar dezenas de milhões de dólares para fazer isso, mas isso é muito melhor do que "impossível"! E esperamos que esse custo caia drasticamente, à medida que as pessoas se baseiam em nossa pesquisa.
Este é um post de convidado de Andrew Poelstra. As opiniões expressas são inteiramente deles e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.